Interesting... but I wonder, does this actually solve any problem? I can see your reasoning from a typing theory point of view, but I'm not convinced that the additional complexity actually comes with any advantage.

Of course, this has advantages. I added an actual example.

To clarify, this is the failing case:

import haxe.ds.Option;

class Main {
	static public function main() {
		var optionFloat:Option<Float>;
		var optionInt = Option.Some(1);
		optionFloat = optionInt;
	}
}

Your direct assignment works already due to top-down inference.

And yes I can see the point here. Given that enum arguments are read-only, covariance could be allowed.

@ncannasse: Any opinions?

The problem is that type parameters variance depends on the way it's used.
For instance:

enum Option<T> {
    None;
    Some( f : Void -> T );
}

In this case T is contravariant...

If you mean this Option1, yes, the Option1.T is contravariant.

enum Option1<T> {
    None;
    Some( f : T -> Void );
}

However, Option1 is different type from Option2:

enum Option2<T> {
    None;
    Some( f : T );
}

Option2.T is covariant without regard to usage.

This is the list of "A is B" relation:

We have decided to reject this proposal in our haxe-evolution meeting yesterday.

We concluded that we should approach this in a broader scope, not just for enum, but also in other cases, especially with "read-only" types (e.g. HaxeFoundation/haxe#9611).